It is common today for a business or similar entity to utilize a voice response unit (VRU) in conjunction with a communication system and host information processor system in order to automate responses to client requests for services or information. Typically, a VRU is implemented at a business location as a subsystem interacting with the business' telephone communication system, such as a private branch exchange (PBX), and data processing system.
The VRU subsystem itself is a processor-based system requiring an operating algorithm in order to interact with the PBX and data processing host such as a LAN, according to the entity's desires in response to their client's inputs. This algorithm is a complex set of instructions including: menu hierarchies including lists of options and their related functions; static messages to be used alone or in conjunction with spoken variables; and host interaction instructions to retrieve and store variables and information.
It is the development of this complex set of instructions wherein a problem common in the art today lies. In order to create an algorithm capable of accomplishing the automation of responses desired by an entity in response to inputs by their clients, very detailed information must be gathered from the entity. This information includes specific verbiage to be spoken to prompt for input as well as to present requested information. Additionally, details as to the call flow, or what information should be presented at what point in the conversation are necessary. Call flow information includes considerations such as at what point the conversation should branch in response to client input/request. Moreover, if client requested information is to be presented in the call flow, consideration must be given to the point at which any information required for retrieval or authorization of the information is to be provided.
Presently, this information is gathered by a VRU vendor/supplier by putting a specification writer in contact with the entity desirous of a VRU application. Because of the nature of the VRU, this process of gathering information typically encompasses many aspects of an entity. Therefore, multiple representatives of the entity are often required to provide input in the VRU specification process, adding to the complexity of the specification process. The entity's representatives contributing to the specification may include representatives of such areas as sales/marketing, management information systems (MIS), legal, and quality assurance (QA).
The specification created from the interview process is generally a very thick textual document that is necessarily very technical as it is to be utilized by the programmers who will actually be developing the VRU algorithm according to the needs of the entity. Its contents include all the information necessary to implement the desired VRU. Specified in the document is the interaction with the caller, all the different branches that the VRU script can take, all the error processing, all of the host processor interactions and/or database interactions required as well as most of the calculations required to present the desired information.
The specification is presented in a format of pseudo programming code which includes reference to variables and jumps to various pages of the document corresponding with branching of the call flow. This format provides a very detailed representation of the VRU application, but such complexity necessarily creates a cryptic and difficult to comprehend representation, especially for those not experienced in reviewing such information. Although cryptic, this information is a precise blueprint from which the programmer will program the VRU.
The entity desirous of the VRU application must agree that the product specified in the specification is indeed the product they desire. However, because of the specification's very technical and cryptic nature, it is seldom readily apparent that the product detailed in the specification is indeed what the client desires. For example, there is no general overview of the VRU application that may be had to better understand the call flow possibilities supported by the VRU application.
To complicate the matter further, typically the lengthy specification must be reviewed by several representatives of the entity, each with an eye toward a different aspect of the specification. For example, a product manager may review the specification to verify that information concerning the entity's products are presented in a meaningful format. Likewise, a MIS manager may review the specification to verify that all information required to retrieve a piece of information from one of his/her systems is gathered by the VRU prior to the point at which it requests information from the host processor. Similarly, a review of the actual verbiage to be spoken may be required of the public relations and/or legal department. Those reviewing the specification shall be referred to hereinafter as "consumers" of the specification. Other consumers may also be required to review the specification, either in whole or in part, such as a project manager, company president, or telephony expert.
The vendor/supplier of the VRU application may also have consumers of the specification. These consumers may include application programmers, application QA personnel, modifications programmers, and project manager.
Although all of the specific information necessary to implement the VRU algorithm is contained within the prior art specification, it is typically inter-mingled with various other information contained within the specification. There is no navigation means by which a consumer may easily identify areas of the document or VRU application in which he/she is interested. Therefore, each consumer, whether interested in the entire document or only in particular information contained therein, must review the entire specification. This can cause the consumer to inadequately review the specification because of an inability to wade through the entire document to obtain a good understanding of particular information they are concerned with. This problem is compounded by difficulty in understanding what is presented because of the specification's highly technical and cryptic nature.
Furthermore, a review of the verbiage of the VRU dialogue in text form, as presented in the specification, does not give the consumer an accurate impression of the actual dialogue that will result. There is a great deal of difference between reading words on a piece of paper and hearing them. Specifically, the pace is much different between the spoken dialogue and the dialogue as read. This difference is compounded by the format of the specification necessitating leafing through pages at every branch of the dialogue.
Therefore, the use of the prior art specification can result in the necessity for modification of a completed algorithm created from the specification even after a review by representatives of the entity utilizing the VRU. Such modification is necessitated by undesirable aspects of the VRU not being recognized as they appeared in the specification document.
Additionally, the complexity of the specification causes revisory iterations to take a considerable amount of time. Not only does the initial creation of such a detailed document require a significant amount of time after the initial specification interview, but once the entity has been given the document it takes a considerable amount of time for their representatives to review and absorb it. Thus, there is a long delay in terms of real time spent before a vendor can reiterate and make changes.
More recently developers of VRU algorithms have utilized graphical development environments. Such graphical development environments use icons to represent various call flow components with lines or arrows connecting these icons to indicate the call flow. One such graphical development environment is disclosed in U.S. patent application Ser. No. 08/599,134, entitled "ENHANCED GRAPHICAL DEVELOPMENT ENVIRONMENT FOR CONTROLLING PROGRAM FLOW," having a common assignee, incorporated herein by reference.
Although the use of graphical development environments aid the consumer in understanding the call flow by depicting it in graphical terms, the generated diagrams are merely supplemental to the detailed specification. The specification must still be reviewed by the various consumers, as some of its information does not appear in the graphical representation. Furthermore, the detail of the dialogue is still present with all its variables and branches. There remains complexity inherent in this detail that cannot be simplified merely by presenting it in graphical form.
Additionally, these graphical development environments are designed to aid in the understanding of the detailed specification and for the subsequent coding of the VRU algorithm after information regarding the entity's application of the VRU has been gathered in the interview process. The complexity of such environments typically do not lend themselves to their utilization in the initial interview process to aid in the first iteration of development of the VRU dialogue.
Moreover, the complexity included in such graphical development environments limits their use in navigation in the detailed specification. Although, the call flow is presented graphically, there is considerable detail included. Therefore, the graphical development environment does not present an easily comprehensible representation of the call flow from which a consumer may readily identify an area of interest within the specification or VRU application.
Furthermore, the use of graphical development environments does nothing to address the problems associated with differences in reviewing VRU dialogue from written word rather than spoken dialogue.
Therefore, a need in the art exists for a VRU dialogue development tool which presents VRU specifications in a format readily understandable by the various consumers which must review the specification.
There is a further need in the art for a VRU dialogue development tool capable of presenting a sample of VRU dialogue in an audio format, prior to completion of VRU programming.
There is a still further need in the art for a VRU dialogue development tool capable of producing specification documents directed to individual consumers charged with responsibility to review individual aspects of the VRU specifications.
There is yet a further need in the art for a VRU dialogue development tool suitable for use in the initial specification interview process.
There is a need in the art for a VRU dialogue development tool which provides a readily comprehensible overview of a VRU dialogue. Additionally, there is a need in the art for a VRU dialogue development tool which provides navigation between this readily comprehensible overview of a VRU dialogue and a detailed representation of the VRU application implementing that dialogue.